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An efficient real-time transport protocol multiplexing method and apparatus for transporting compressed speech between IP telephony 
gateways. The protocol eliminates bandwidth usage inefficiencies in transporting short packets between nodes connected by an I£ network, 
wherein the method and apparatus enables a number of users to share a single RTP/UDP/IP connection. The protocol includes creating a 
header for a plurality of data packets, each header providing identification of a user associated with a packet, adding each header to the 
data packet associated therewith to form mini-IP payloads, multiplexing the mini-IP fpayloads into a RTP payload and transmitting the* RTP 
payload over a single RTP/UDP/IP connection! " " 
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METHOD AND APPARATUS FOR PROVIDING USER MULTIPLEXING IN A REAL-TIME PROTOCOL 



5 " BACKGROUND OF THE INVENTION ' 

1. Field of the Invention . 

This invention relates in general to a IP telephone, and more particularly to a 
method and apparatus for providing efficient user multiplexing in, a real-time 
t-ta ^'protocol payload for transporting compressed speech between EP telephony 
10 " gateways. 

* 2: Description of Related Art . 

•An organization's computer network has become its nervous system. 
: " v - r : ^bigarii^ and^hosts into Local 

w ' """" > "Area'Network (IJAN) communities. These Local Area Networks have been 

1 5~: 5 1 v coimecte^ Netwwks (WANs). It 

has become a iiec«s&^ operation tlTat pairs of systems must be able 

r ' ; to comi^^ they may be located in 

the network. v • 
v " : ~ ^ .'pffing the e^ly years bf network com^ 
; - 20 v " pfbtbcols we'rc ^However," the de^^^ Systems 

v Ut -'"'-*'' r '' %tercorinectioh Referenced -for 
. .v ; . Standardization (ISb)'Kas led ip aiiimprc^ which 
generally allows end-user applications to in a 

:network. Implementations are based on written standards that have been made 
^ 25 u available by volunteers from dozens of computer : vendorsrh^dware cbmponent 



Dunng the last decade, LANs have been proliferatmg. This has created a 
recurring problem ot how to minimize congestion and optimize throughput that must 
be solved by network managers. An early solution was to simply divide Local Area 
" 30 * Networks into multiple smaller networks serving smailler populations. These 
segments were connected ly bridges to form a single Local Area Network with 
traflfic^being segregated "locally to each segment. 

* ' ' Ail Internet is a set of networks connected by gatewaysVwhich are sometimes 

referred to as routers. The Internet Protocol (IP) is a network layer protocol that 

1 
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routes data across an Internet. The Internet Protocol was designed to accommodate 
the use of host and routers built by different vendors, encompass a growing variety 
of growing network types, enable the network to grow without interrupting servers, 
and support higher-layer of session and message-oriented services. The IP network 

5 layer allows integration of Local Area Network "islands". 

The Internet not only provides a medium for data transport, but also has 
developed as a medium for telecommunications. In fact, IP telephony is maturing as 
a technology and a service, which places it in direct conflict with the conventional 
public telephone network. New types of IP telephony equipment are being 

1 0 introduced and small Internet service providers and niche carriers are beginning to 

offer IP telephony services. 

However, while IP telephony, or voice-over-IP, has great potential to 
compete against the traditional public voice network, many obstacles must first be 
overcome. For example, the quality of Internet telephone calls is not as good as 
15 public network calls. Customer interest in the United States-where long-distance 
prices have consistently fallen-is uncertain. Further, IP telephony network 
equipment is new and lacks features that carriers desire. 

Consequently, only a handful of small telephone companies now offer IP 
telephony services, and the amount of traffic they carry is minimal. However, 
20 equipment vendors and carriers are moving quickly to overcome these problems and, 
according to analysts, the number of established carriers beginning P telephony 
trials is rising rapidly, new carriers are jumping into the market and the number of 
services being offered is expected to increase dramatically. In fact, analysts predict 
that users will embrace the new IP-based voice services. 
25 Accordingly, the success of Internet has further consolidated the notion that 

IP is the dominant transport protocol in access networks. The penetration of Internet 
and subsequent IP connectivity to homes and businesses have given impetus to 
integrated services over IP which means voice, data and video over a single IP 
network. At present, IP networks offer a single class of service called best effort, 
30 which<^notguaranteeanyQualityofService(QoS)toapplications. Tosupport 
delay sensitive applications such as voice and interactive multimedia, there have 
been many proposals submitted to the Internet Engineering Task Force (IETF) on 
how to integrate QoS in IP networks. These proposals include differentiated service 
(diff-serv), Integrated services (Int-serv) and Multi Protocol Label Switching 
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(MPLS). Despite these efforts, QoS in IP is still elusive and could take some time 
:v before it is deployed over global Internet 

As mentioned above, IP telephone has emerged as a potential application to 
challenge the traditional phone companies by offering long distance telephone 
5 v . service over Internet for low prices. There are a large number of equipment vendors 
offering IP telephone gateways and accessories to : provide JP telephony service to 
!>-■■■■*. corporate customers and Internet Service Providers (ISPs). IP telephone standards 

such as H.323, H.225 and H.245 have been standardized to enhance the rapid 
,^ . deployment of IP telephone services in global Internet. Even though, IP telephone is 
, .10 r .not a reality in publicJnteniet today, it has been successful in Intranet and Virtual 
.. ?r , Priy^eNet^rks^ < /;* • f . 

':?uz'i* u t; ;;Jhere ; is;a^ once 
QoS issuesin IP networks become a reality. However^ IP networks offer only best 
tjf^ji. r H j|effi»t s«^ce y .whereas .delay^sensitiye applications such as voice and interactive 
.; , . ,1:5 f ~. : .. : videp ?eguire a deterministic ;giiai^tee / pn)the delay, ^delay variation , and packet loss 
jzzisz from the network. As can be seen then, this lafck of QoS ;guarantee 4n IP networks is 
vuA 'jtc tout( ?^ as.the major problem^ over 

r : vl^teniet, To overc providers over 

provision the links (networks) that interconnect IP telephone gateways. This 
2p : , - less delay thus 

•c\ ♦ . providing ;a reasonable^ v^ as 
cm C\ *r> traditional 
a*?** ■*>■• e telephone n^o^^ a resi^ telephone, gateways in corporate 

* - uy ;*:uKv:^^^ the;coming years. 

cr^S^-j'iC t: .Jraditionally;vp^ switched network with connection 

0 : :: ,: ; , ^^fifinted model. T^^i^iye growth of data traffic in the network has changed the 
- ( 4 notion . of. service specific networks (single network fo^ Voice over 

. £^IP network enables ^ public>branch exchanges \(PBX) and public 

;vv .*. :;; l . ■ ^Y^9l^?^ : ^?^P^one < network „(P S TN) , users * to • share r the - data : network thus improving 
, tlr . r 3p, r .r; *tlpnetwork^ Ipng distance telephone 

network. IP telephone gateways act as andnterface between the existing PSTN and 
: x : _ \ r. , PBX networks and IP networks. This method allows one PSTN user to call another 
r j h .PSTN user .connected through IP telephone gateways thus eliminating the need for 
long distance telephone network, .c;- - * r . ;. 

3 
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In a IP telephony connection, two sides of the PSTN/PBX users (two 
branches of the same company) are interconnected by IP telephone gateways. In 
such application, a telephone call between PSTN/PBX users located at either side of 
the gateways is carried by a separate Real-time Transport Protocol/User Datagram 

5 Protocol/Internet Protocol (RTP/UDP/IP) connection. RTP is an Internet protocol 
for transmitting real-time data such as audio and video. RTP itself does not 
guarantee real-time delivery of data, but it does provide mechanisms for the sending 
and receiving applications to support streaming data. Typically, RTP runs on top of 
the UDP protocol, although the specification is general enough to support other 

1 0 transport protocols. The User Datagram Protocol is a connectionless protocol that, 
like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few 
error recovery services, offering instead a direct way to send and receive datagrams 

over an IP network. 

IP telephony gateways provide an interface between the existing circuit 
1 5 switched telephone networks (such as PSTN and GSM) and the packet switched IP 
data networks. In traditional IP telephony applications, telephone calls between 
PSTN users interconnected by a pair of IP telephony gateways to compress incoming 
PSTN speech samples generate packets with sizes ranging from 5 to 20 bytes per 
speech sample. 

20 For example, G.723.1 (the most popular IP telephony codec and the 

International Multimedia Teleconferencing Consortium's (IMTC) Voice over IP 
(VoIP) mandatory low bit-rate codec), generates a 20 byte speech packet at 30 ms 
intervals. Many codecs used in cellular environment generate less than 10 byte 
packet per speech sample. Small size packets are subjected to large overhead when 

25 transferred using the Real time Transport Protocol (RTP). The RTP/UDP/IP 

overhead is 40 bytes (12+8+20) for a simple speech packet. For example, a 10 byte 
packet transferred via RTP/UDP/IP increases the overhead to 80% (40 byte 
overhead/50 byte overhead plus packet). In addition, for each call request a single 
UDP/IP connection (a pair of UDP ports) is established between the gateways 

30 requiring a large state (memory) to be maintained at the telephony gateways, thereby 
making these less scaleable. 

Congestion in IP networks results in packet loss at routers and UDP does not 
have any retransmission mechanism to recover lost packets. Also, real time 
applications such as speech is intolerant to delay caused by re-transmission. In 

35 traditional RTP method, each individual speech packet is transmitted as a IP packet, 
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which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss at IP routers. 
It can be seen then that there is a need for a method:and apparatus for 
. eliminating inefficiencies in transporting- short;packets between JP.telephony 

5 gateways connected by an IP network..- _ fc ; • ^ . t 

: . ' ■: - •;. v It can. also bje seen that there is a need for.amethod and apparatus that 
r -^..gnables^numberof users, to 

'=*. ;/ <!.-;, rr- * ' SUMMARY OF THE INVENTION 

lQcr, . .To overcome the, limitations in the;prior art described above, and to' T 
v ; ;.: ; .*v overcome ;other limitations 'that will become apparent uponreading and 

understanding the;present specification, the present invention discloses an efficient 
kt'^r •^■reaiKtime tr^^q^protocol multiplexing method and apparatus for transporting 

x4^:>iuvr^ *;^he preset providing a 

i ^? iv * method ^d^apparatus for eliminating inefficiencies in transporting short packets 

between IP telephony gateway s connected by ,an IP fretwork, whereurtiie method and 

connection. 

r^~ ; :' - ^7 :u ^;A : protqcpIm;accori of the present invention includes 

tv pfe*^ ^f a : u^^^ 

6 f ;^t^re^h4p fom into a RTP 
c K?i' I^p_aylpM.^ 

Other embodiments:pf a system ; in accordance with" the principles of the 

c-k : 25/ : /inyention:may includ^ alternative prnoption^ ; additional;aspects. One suchlaspect of 

:;m&&L l ii -Ae present inyenti is;that theplurality of datapackets, are received from two or 

ifz&mkr: ^r;mp users, ~& • ^ -c z.&'-vkr± ^ife^i-: • h.^-rJ;^. 

/- ■ . * ■ ■ ■ - 

i:^^cr; ^^other is that the identification of a user 

further comprises a unique channel identifier for each of She two ormore users. 

n*jii.r3Si.to *:nr,Mpther;asp^ identifieflis 
V m v^assigned-^ 

network. x^i^-rrrr. .vnrjv^:-- >■ i " v/v.:^ ^cjI a* *\ i™.*. 
:.v w -ur::;v ; Another, aspect of &e present invention is that the header compri^^ a length 
.. r : n v -indicator, the length indicator indicating the size of the data packet associated with 
35 the header. . -o ->::••• 

5 
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Another aspect of the present invention is that the length indicator comprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

Another aspect of the present invention is that the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 

5 user to identify data packet loss. 

Another aspect of the present invention is that the sequence number further 
comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

Another aspect of the present invention is that the header of each data packet 
1 0 multiplexed into the RTP payload is transparent to intermediate IP routers. 

Another aspect of the present invention is that the protocol further includes 
de-assembling the RTP payload back into the data packets. 

Another aspect of the present invention is that the protocol further includes 
receiving at a local gateway an access request from a user at a remote IP gateway, 
15 transmitting a setup message to the remote IP gateway using an IP connection and 
establishing a user plane connection for receiving data packets from a user after 
successful completion of a connection setup. 

Another aspect of the present invention is lhat the protocol further includes, 
after receiving an access request from a user, determining whether an existing 
20 RTP/UDP/IP connection is available, using an existing RTP/UDP/IP connection 
when an existing RTP/UDP/IP connection is determined to be available, creating a 
new RTP/UDP/IP connection when an existing RTP/UDP/IP connection is 
determined not to be available and creating a setup message using a local UDP port 
number, remote port number, channel identifier. 
25 Another aspect of the present invention is that the protocol further includes 

recovering, at the remote gateway, a local UDP port number, remote port number, 
channel identifier from the setup message, verifying at the remote gateway whether 
the channel identifier is free and accepting the connection when the channel 
identifier is free. 

30 Another aspect of the present invention is that the accepting the connection 

further includes updating a channel identifier table at the remote gateway and 
replying to the local gateway with a connect message. 

Another aspect of the present invention is that the protocol further includes 

replymgtomelocalg^ 
35 connection occurs. 
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Another aspect of the present invention is that the protocol further includes 
. . . . receiving at the local entity the connect message, confirming at the local entity the 
channel identifier and informing the user requesting access. 

Another aspect of the present invention is that the protocol further includes 
5 controlling the multiplexing and transmitting of the RTP payload using a timer. 

:; i; _ , Another aspect of the present invention is that the data packets include 
.... .compressed voice data. . r ,r t . : r - -v 

An IP telephone network according tovthe present invention includes a 
, . L ... G ; remote IP gateway and a local IP .gateway, wherein the remote and local IP gateways 
1 0 communicate using the protocol. . : <+ .^r^v- 

, • v : ,A MINI-IP controller according to,the : present.invention includes means for 
providing control plane signaling, control plane signaling being used . to setup a 
connection to a remote peer Ml^-ff contrqUer.and means for providing user plane 
. ^ , signal, : user plane signaling being used to transmit data packets to a user associated 
15 with the remote peer MINI-IP controller using the protocol, ^r : : ; c 
i, af ;;,; an RTP-header, 

a plurality of data packets representing data, from a.plurality of; usefs«and a plurality 
r , -o£MIMtIP headers;«ach of the ; plurality having a}MINI-IP header 

attached thereto, each of the MINI-IP headers comprising a user identifier for 
y>irt'j2$yj identifying one <>f the; plurality of users being associated with each of the packets, 
and each MINI-IP header and packet combination forming a MINI-IP payload, the 
; z>^;:i.:::v: form a RTP packet. 

A base station, base station .controller and mobiles switching center according to 
cy:^^h':.r>::<;i~ |hf present mvention inefficiencies in 

25 transporting packets using the MINI-IP protocol. ; .r -r ri £H 

These and various other advantages and features of novelty which characterize 
the mvention ^ annexed hereto and form a 

c cvr^P^ better understanding of the invention, its advantages, and 

ithe;pbjecte i obtain^ which form a 

. : 30 v: %&erparthereof, and 

■ :is: i r : illustrateid.and ; described specific examples of an apparatus in accordance with the 
. invention. . r 7f , r r : , ^ . >: . * - .. 
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m?F pCQrPTPTTnN OF THF. DRAWINGS 

Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: po™/PRX 
Fig. 1 shows an application scenario in which two sides of the PSTN/PBX 
5 are interconnected by IP telephone gateways; 

Figs 2a-b illustrate MINI-IP headers according to the present invention; 
Fig. 3 illustrates the multiplexing of MINI-IP payloads in a RTP packet 
using the MINI-IP header; 

Fig. 4 illustrates the location of the MINI-IP controller in a IP telephone 

1 0 lavered model; 

Fig. 5 illustrates the user plane and control plane in a MINI-IP gateway 

environment; 

Fig 6 illustrates an example of a CID table; 

Fig. 7 illustrates the use of the TIMER_MUX according to the present 

< 

15 inVenti Hg. g illustrates the application of MINHP being restricted to transport 
voice users between IP telephony gateways; 

Fig. 9 illustrates the application of aMINI-IP controller in aradio access 



network; 



Kg. 10 is aplot of the number of users on a single RWUDP/IP connection 
versus the bandwidth in Kbps for Q.723.1; 

Rg. , 1 is aplo. of the number of users on a single RTP/UDP/IP eonnechon 

versus the bandwidth in Kbps for 0.729; and 

Hg. 12 illustrates a comparison of the percent overhead verses the number of 

25 users for different methods. 

r m n rrnnF.r H' r"™ 1 "fthf INVKNTIQM 
tothe following description of the exemplary embodiment, reference is made 
,o the accompanying dmwinga which form a pari hereof, and in which is shown by 
3„ C„f illusion the specific embodiment in which the invention may be practiced. 

my be made without departing from toe scope of the present invenhon. 

The present invention provides a an efficient metirod and apparatus for 

35 ^lectedbyalPnetwo*. The present invention enables a number of 
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low bit rate connections (compressed speech) to share a single RTP/UDP/IP 
connection, thus reducing the RTP/UDP/IP overhead. A. MINI-IP header (2 byte) is 
.added to each packet from an user before it is assembled with packets from other 
users into an RTP pay load. To identify individual users on a single RTP/UDP/IP 
, :5 connection, a unique Channeljdentifier (CID), as a part of the header, is proposed. 
Channel ID negotiations between .the peer gateway entities is carried out by a new 
signaling procedure called MINI-IP signaling. Analytical results show that the 
t - . MINI-IP method reduces the pverheadfor short packets by 60% thus improving the 
: , bandwidth efficiency. Other advantages of the present invention include a decrease 
, r 10 . in the number of UDP/IP. connections between gateways and a decrease in. the traffic 
: v /• congestion at intermediate IP routers. The present invention may :be implemented, 
r for example, in IP telephoneigateways, Radio Access Network (RAN) access nodes, 
t and IP access nodes by simply adding an external MINI-IP control module. The 
j -^wi - - -.MINI-IP r methpd uses the, existing bearer protocols, suchmRTP, TCP, UDP ad IP 
r&r-\ ^ -u: ^d^flo^s not require any changes to .the traditional IPnetwofkTfimctionalities. 
„\LaL1 h^iz •> *rc^ 1 ^^S > ^yvyP^-^.'P^ e d. in.a circuitswitched network with connection 
a**, is - l : -oriented model. k The : explosiye growth of datatraffiain the network has changed the 

notion of service specific networks (single network for single service). Voice over 
■-.vv.* IP network enables.the voire traffic from PBix and PSTN users to share the data 

&rr.%:* ,;betwe^ method 
iJ? allpv^s one PSTN userto call. another PSTN user; connected through IP telephone 
Sj^>F .gateways^lhus-eliminatm 
■ t j - r ,25 pAt*. ^ £ Fig. 1 shows an application 'scenario lOO.in.whichtwo sides of the ,2 

f.7~- ; u PSTN^PBX 100, 1 12 -(two branches of the same .company) are interconnected by IP 
ui ^j\XaVGi>_I ^telephone gateways 120, 122. In such an application, a telephone.call between 

i>. ^ .RS^/PBX users 110,; 1 12 located .atieither sideiof the gateways 120; 122 is carried 
t ♦ "ty ?: s . e P^t e f?^ codecs used at the telephone gateway to 

l -^30 , x y ..compress bwming^PSTN/EBX voice calls generates packets with a size ranging 
from 5 to 20 bytes, - o l ^ v*r ; • r.- • 

; ' • \s< i rr ; For example, the IP.telephonetstandardtG.V^.Lspecifies a codec that 
. generates^, 20 byte packet at the intervalof 30.ms ; speech sample. -Many codecs 

. used in cellular environments generate a small packet, e.g., ;on the average a 10 byte 

9 
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packet per speech sample. This small size packets require a large overhead when 
they are transferred using the Real time Transport Protocol (KIP). 

The RTP/UDP/IP overhead is 40 bytes (12+8+20) for each speech packet. 
For example, ifalObyte packet is transferred via RTP/UDP/IP then the overhead ,s 
5 80% i e 40/50. In addition, for each call request a single UDP/IP connection is 
established between the gateways 120, 122 requiring a large number of states 
(memory) to be maintained at the telephone gateways 120, 122. 

h avean y retransmissionmechanismtorecoverlostpackets.Also,realnme 

l0 applications such as speech \\ 
traditional RTP method, each individual speech packet is transmitted as a IP packet, 
which generates a large number of packets between gateways. This heavy traffic 
volume is a potential situation for congestion and packet loss at IP routers. 

The large overhead to transfer a small packets (compressed speech) through 
15 RTP/UDP/IP has been one ofthe drawbacks of IP telephone. In order to mimmrze 
the overhead, RTP/UDP/IP header compression is applied for slow speed links. 
However, this method requires compressing/decompressing at routers as well as 
some additional processing overhead. 

Figs 2a-b and 3 illustrate the use of MINI-IP headers to reduce header 
20 overheadaccordingtotheMINI-IPprotocol. According to the present invention, no 

compressionisutUized^ 

Overhead is reduced by multiplexing two or more(e.g., up to 256) lowbit rate 

illustrated in Fig. 2a. Alternatively, overhead may be reduce using the MINI-IP 
25 hea der204illustratedinFi g .2b. However, those skilled in the art will recognize 
thatthepresentmventionisno^^ 
headersLtr^^ 

Figs Za-barepresentedforUlustrationonly. Rather, those skilled in the art will 
recognize that the MINI-IP headers 202, 204 enables multiplexing of multiple small 

packets as an RTP payload, as illustrated in Fig. 3. 

To identify a single user among the number of users sharing the RTP 
connection, each user is allocated an unique Channel Identifier (CID) whichh 

negotiatedduringconnectionse^^^ 

by MINI-IP signaling, which uses a TCP/IP connection for reliable transport. The 
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most suitable application scenarios for MINI-IP method include IP telephone 
gateways connecting;PSTN/PBX/GSM users. 
. To identify mini packets multiplexed on a single RTP pay load, MINI-IP uses 
: a two byte.header, called MINI-IP header, for each mini packet. The MINI-IP 
,5 , ; header 202, as shown in Fig. 2a includes a Channel Identifier (CID) 2 1 0, a Length 

Indicator (LI) 212, and a Sequence Number (SN) 214. The MINI-IP header 202 
f ; . allows many users to share a single RTP/UDP/IP connection thus reducing the 
. RTP/UDP/IP overhead per packet , _ ■;>,;. * . ^ y > : 
: : . u , J As illustrated in Fig. 2a, the MINI-IP header includes a CID field 2 1 0, which 
10 identifies a single : iiser among users harin^ ACID 
- .210 is assigned .at the time of the request for access to -the IP network and it is 
- unchanged throughout the cpnnection time. /The lengthqf the CID : field 210 is 8 
v : bits, which limite Ae niraber .of users persingle R^ connection to 256. 

i; vr . , r.. T:: ^e;.LJfieJd 212 indicates the size of the pay load ^speech packet) and the 6 

field.212 

:..,^r allows ; different codecs to : s^ aiid pffers,the flexibility to 

, f - : « transport^y .to^ connection using MINI-IP T method u: Ilie size of the LI 

field 212 is limited to 64 bytes since most of ^codes wailable today (G.723.1, 
u 41 : 1 . P-729) generates packets less^than 20 bytes per speech sample. 
CL7il-,2pi;.- J2 bit Sequence :N 

ri ; , ; :^ can be used at the 

*};--VC&*'.-$& rcceiyer to identify ^-pacto will be able to identify up 

:i7: ; :t >L*P 3 consecutive packet losses atiP;layer. r- . rv 1 1 _ ~\:: t }i.:^ 
"\f-: F. s .r v ..;;-r vl^?^ Identifier 

y: jl^/ ; 25. ;> A (C^^ 2 16, and.a Reserved bit 

.. 'r~:k ^ which 
}s\r<x-Jr aUowstamax^ When 

the total number of users exceeds 256, a new ^ RlTyTJpp^comiecti.on is established. 
7t a: . The LI field 212 is. a 6 bit field which allows a maximum payload size of 64 bytes, 
r*; "k 3Q :v? , : .The Transition that was 

applied to a mini-packet. Notification of such changes .occurs by toggling the bit. 
Finally, the Reserved bit (X) 21 8 is currently undefined, but may be used, for 
r example, as an indication of a header extension and.Dual Tone Multi-Frequency 
(DTMF). , ; - r:; ; 

• '/ ' ' ' ' " i 
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As mentioned above, those skilled in the art will recognize that (he above 
Mustration of MINI-IP headers is not meant to ltait the invention, but drat other 
MINI-IP header configurations and sizes could be used in accordance wuh the 
present invention. For examp.e, .be .engflt of the fields cou.d be -dified withtn the 
5 2 byte format. Ftnther, other fields could be substMed and me length of the field, 
is uotmeantmbelimitedmprovideaMOT-IP header of2by<es. For example, the 
^edbUiUnauntedinFig^bmaybeset^nMomdicateane^nsionhead, 

, ncl „d.d in the MINI-IP header thereby providing an overall lengm for the MINI-IP 
h eaderof3byte,Al.ernafive,y,n B re SOT edbi,mayb,se,.o»0- to mdica.e«ham 

,0 ex.eusionheaderisno.includedintoM.NI-IPheader. Nevermeleas, fitose sbUed 

in tire art will recognize mat increases in the overa.1 size of me MM-IP header w.,1 
prop.r.ionallymcreaseme.otmoverheadwhenmultipleMINl-IPpacke^ 

mulfiplexed,oge.herinacco,da„cewimmemven t ion.Tnns,mosesh..edmmea« 
will recognize mat any MINI-IP header ma, enables multiplexing of multiple small 
15 size packets, is added to each mini packet before it is assembled with other muu 
packeKasanRTPpayloadasfflnsW.edinFigS.andwhichallowsproper 

processing of the multiple mini packets may be used without departing from the 
scope of the present invention. 

He assembly of mini packefc into a single RTP/UDP/IP payload 300 ts 
20 showninFig.3. a ertumpacke K 310fo.low*eRTPheader312andeachmm, 
pK ket320isdel i nearedbymc W oby te MrNI-lPheader312. 
quires a simple de-multiplexing algorithm a. dte receiver. Bemuse the MINI-IP 
header 312 in the RTP payload 300 is transparent to the intermediate IP routers, the 
MINI-IP according to tire present invention does no, cause any problems m tesma of 
25 ffpacketforv^rdingandomerfimctionalitiesattolPlayer. Tne tradition* Header 
Ertor Couttols (HEQ found in many protocols is excluded because MOT-IP reues 
on the higher layer checksum (HDP checksum) to protect the headers and payload 
from any transmission errors. 

The MINI-IP controller is the key element which will be added to a IP 
30 telephonegatewaystoimplementtheMINI-IPmethod. The major function of the 

MINI-IP controller are: 

i Negotiate channel identifier with remote gateway upon a 

RTP payload 
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Hi. De-assemble MINI-IP packets from the RTP payload 
iv. Communicate to the remote controller to forward any request 
and/or control message * 

5 The location of the MINI-IP controller 4 1 0 in a IP telephone layered model 

; 400 as shown in Fig. 4. The MINI-IP controller 410 is inserted between the I WF 
~ function (not shown) of the PSTN/GSM/PBX network 420 ;aiid the RTP modu^ 
in the IP telephone gateway. The MINI-IP controller 410 is capable of receiving 
connection request from PSTN/GSM/PBX users 420 and settihgoip, a channel on an 
10 ; existing or a new RTP/UDP/IP connection. The MINI-IP controller 410 acts as an 

\ : ,appjicatic>n to; the layers below 422, 424, 426, 428 (RTP/UDP/IP) .and uses. the bearer 
_ , .- . services i offered by lAe lower layers for effective m^ Qtherjfunctions of 

.>, r the controller include operand close RTP/UDP connections,;keep track of the active 
C - jusers : on rail UDP connections, and provide interrworking with'PSTN/GSM/PBX 
15 callicontrol features. ;; t \ : ^scul*: ^. pa^^ri^ 

. cu^v^0£ us ^ environment 

500 sho^:in : Fig. ,!5^Thecont^ peer 
Tj r^- , <entities:required to negotiate; a channel for an "incoming calhfequest" on an existing 

setupimessage will be 
,20 : iM^smitted upon. receiving a call request from a PSTN/GSM/PBX user 530. The 
setup-message include UI?Pj connection identiiSefs and'CID.j The control signaling 
s 520 is c^ed^by iaJTCP/K connection 540 for assured data transfer. - The user plane 
zt c,± 510 ^sociation is made after a successful connection setups The user plane 510 data 
~.ff is carried over RTP^ppP/IP 542;similarito the audio and Video transport over 
; 25 . ; ^ ;networks.r ;i: • ~7^.r A xn ^w,^. i-^X^px- Mt^&z&x^rkz. 
: ; ( ^ / f v; T^e MIM Lv 
^ : PS^^BX/QSM user 53 0 triggers.iaiCID setup sequence betweenuthe peer MINI-IP 
/^xo^^ verifies if there is any 
c . . e)d^ting;RTP/iro If there; is none or any 

30 existing connection(s) is full (no free CID) then the MINI-IP controller 520 
: . j ;;■ establishes a new/RTT^/UDP/IP connection. \The;new:UDP '^connection is established 
^ ^throughout UDP sockets; If there -exists a UDP connectiomand free; GIDs for the call 
: ■ -request, then MINI-IP uses the same UDP port number.; A setup message is created 
. ~ with the local UDP port number, remote UDP port number, .and CED number, and is 
35 , transmitted .to the .remotegateway.. ~; v . ; L . * •/ • ^>^ : 
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The remote gateway 560 recovers the information within the setup message 
and verifies that the requested CID is still free on its local table. If the call can be 
accepted then the local gateway 562 updates its local CID table and replies with a 
connect message. 

5 Fig. 6 illustrates an example of a CID table 600. In the CID table 600 of Fig. 

6, CID 25 610 is assigned and CID 26 612 is idle. The local. UDP port number 620, 
remote port number 622, local user ID 624 and remote user ID 626 are provided for 
each CID that has been assigned. 

Referring again to Fig. 5, if the remote gateway 560 experiences any problem 
1 0 in allocating the connection, such as CID collision, then it transmits a rej ect 
message. The CID collision problem can be solved by existing schemes used in 
other protocols. Upon receiving a connect message, the local entity 562 confirms 
the CID association and informs the corresponding user 530. The MINI-IP 
signaling is closely associated with the call control signaling used in 
15 PSTN/GSM/PBX networks. The MINI-IP controller 550 establishes a user channel 
only within the IP network. Those skilled in the art will recognize that the call 
control signaling outside the IP network is beyond the scope of MINI-IP controller. 

At the time of assembling mini packets into an RTP payload, a timer controls 
the waiting time between the placement of a first packet in the RTP payload and the 
20 time to transmit the first packet to the remote peer. This timer (TIMER_MUX) is 
essential to control the delay accumulated at the multiplexing end for voice packets. 

Fig. 7 illustrates the use of the TIMER_MUX 700 according to the present 
invention. In Fig. 7, mini-packets 710 are received at a scheduler 712. The 
scheduler schedules packets for assembly into an RTP payload by placing packets 
25 into a packet assembly buffer 720. Upon expiration of the TIMER_MUX 730, an 
RTP packet is transmitted. The TIMER_MUX value depends on the link speed and 
transfer delay. The higher the TIMERJMUX value the better the bandwidth 
efficiency. However, higher TIMER.MUX value could increase the delay for voice 
packets. 

30 Speech is somewhat tolerant to packet loss when compared to data. But, 

beyond a certain limit, packet loss renders the speech inaudible and causes 
inconvenience to the user. Communication media are not error free and any data 
transmitted needs some sort of protection. Existing protocols such as ATM, IP and 
AAL2 specify a Header Error Correction (HEC) to detect errors in the headers at the 
receiver. Protocols such as UDP offers both header and payload protection. The 
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UDP checksum is calculated for the entire UDP packet including header and 
payload. The MINI-IP header is 2 byte long and does not have any HEC field 
because MINI-IP packets are encapsulated within an RTP/UDP payload thus 
protected by the UDP checksum. 
5 Packet loss is another problem that is prevalent in any packet switching 

network. Since MINI-IP enables many users to share a single RTP/UDP/IP 
connection, MINI-IP can not use the RTP sequence number to identify packet loss 
of a single user. To solve this problem, the MINI-IP header consist of a two bit 
Sequence Number (SN). field. This two bit SN allows for a modulo 4 style sequence 
.10 numbering at the transmitter. In general, SN. could -start at 0 and follow the sequence 
. . ..■ of 1,2,3,0,1,2. . : t r : - . _ ■ ;•• ^ \ . - — . . . _ ; ; 

: Accordingly, if there is a packet loss, then the MINI-IP controller could 

. , detect the loss at individual user level and take appropriate actions specifiedby the 
r , ; operator. As. can be seen, this 2 bit field allows packet loss -protection of up to 3 
• : 15 consecutiye;packets at IP layer.; : ,^JIr>Jv: J !;,;.-; .. ; .: • . . v:; v„ \ - .< 
♦ : ,v?^B- 8 illustrates the application 800 of MINI-EP .being restricted to transport 
Y 0 ^ users between IP telephony gateway s ? Some of the most obvious scenarios 
e.v, . 800 aire shown in Fig. 8. Traditional telephony uisers such as. PSTN 810 and PBX 
r \.\ 820 interconnected by IP telephone gateways 830 is an ideal iscenario where MINI- 

u: yt 20 7 JP improves the bandwidth efficiency of the IP network. .MESfl-IP can also be used 
^ wireless network. -;. v ^ 

. T g : Kg. 9 illustrates the application of a MINI-IP controller in a RAN 900. In 

£ - v- • - this scenario, M^ is part of the BS 912 connected through IP 

: : . : ;ne^ork 920 to another MINI-IP controller 930 at the;radio network controller/base 

25 ; ;, station controller (E^C^SC). 932; The base station controller 932 :is coupled to a 
t ; . , « . /mobile syvdtching center (MSC) 940 that includes a MINI-IP controller 942. The 
;• . conversations of a number of GSM telephone users will be transported using IP 

r telephony along with data traffic in the same IP network. . Those skilled in the art 
- • * will recognize that the present invention is not meant to. be'limited the.particular 
, \ : 30 ^ components .of the cellular system illustrated;in Fig. 9. . Rather, .the MINI-P is 

v - meant to be utilizedin MINI-IP controllers in any component connected through a 

wireline or wireless IP network.^ ; . . w - . , ; ..r.-.r ■• ;v~ 
. • •„ , ' As mentioned above, the important reason for multiplexing small packets 
: _ into a single RTP pay load is to reduce 1 the RTP/UDP/IP overhead for each packet. 
35 >( : For example, the overhead is 66.7% in case of 20 byte G.723.1 .packet (40 byte 
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overhead/60 byte overhead + packet) and 80% for a 10 byte G.729 packet (40 byte 
overhead/50 byte overhead + packet). Considering that IP telephone gateways 
transfer hundreds of user at any given time, the overhead for all these users could 
very will exceed the total capacity of the link. However, the MINI-IP protocol 
5 described above reduces the overhead dramatically. 

Figs. 10-12 illustrate the differences in bandwidth requirement of MINI-IP 
and IP. The bandwidth requirement for a traditional scheme (RTP/UDP/IP) is 
compared to MINI-IP and the results are shown in Figs. 1 0 and 1 1 . 

Fig 10 is a plot 1000 of the number of users 1010 on a single RTP/UDP/IP 
10 connection versus the bandwidth in Kbps 1020 for G.723.1, whereas Fig. 1 1 is a plot 
1 100 of the number of users 1 1 10 on a single RTP/UDP/IP connection versus the 
bandwidth in Kbps 1 120 for G.729. The rate of G.723.1 is 5.6 Kbps and the rate of 
G 729 is 8 Kbps. The actual bandwidth requirement for increasing number of users 
is calculated by simply multiplying the number of users and the peak bandwidth. 
15 For example, the actual bandwidth requirement for 10 G.723.1 users is 56 Kbps. 
The bandwidth required by the traditional IP telephone method is calculated by 
adding the overhead of 66.7% (G.723.1) and 80% (G.729) per user. The bandwidth 
requirement for MINI-IP is calculated by adding the percentage of overhead due to 
multiplexing the number of users in a single UDP connection. The results indicate 
20 that the bandwidth requirement for transporting the same number of users through 
MINI-IP 1030, 1130 is very low compared to the traditional IP (RTP/UDP/IP). 

The overhead 1200 of different speech codecs are shown in Fig. 12. The 
overhead due to RTP/UDP/IP is constant for both codecs since the RTP/UDP/IP 
overhead for each packet is constant. MINI-IP method is able to multiplex small 
25 packets into a single RTP/UDP/IP payload thus reducing the overhead to a 

minimum. The overhead due to MINI-IP 1230, 1240 on both codecs provides that 
MINI-IP is efficient in utilizing the bandwidth of the output link. In addition, as the 
number of users on a single connection increases, the overhead reduces further. 
Since MINI-IP utilize the bandwidth efficiently and does not generate as many 
30 individual IP packets, it avoids the congestion at intermediate IP routers. Also, high 
bandwidth efficiency allows the IP packets to be forwarded quickly within the 
network thus reducing the overall delay for speech packets. 

In summary, MINI-IP provides an increase in bandwidth efficiency between 
IP telephone gateways. MINI-IP allows many users to share a single RTP/UDP/IP 
35 connection, thus reducing the IP overhead for each packet. The codecs used in 
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telephone applications today generate an average packet size of 10 byte per speech 
sample. As shown above, the RTP/UDP/IP overhead per speech packet ranges from 
66% to 80%. This enormous overhead lowers the bandwidth efficiency as well as 
causes congestion by generating large number of short IP packets. Traditional IP 
5 telephony gateways that interconnects PSTN/GSM/PBX systems do not utilize the 
bandwidth efficiently, whereas MINI-IP allows a number of users to share a single 
connection thereby reducing the overhead per packet transmitted. The assembly and 
de-assembly processing is compensated in case of MINI-IP because it does not 
require any separate UDP connection and complex.signaling. 

1 0 MINI-IP provides a second advantage of reducing the number of UDP 

connections between gateways by sharing a single RTP/UDP/IP The third advantage 
is that the MINHP method reduces the changes for congestion at intermediate IP 
routers. MINI-IP reduces the number of IP packets by multiplexing mini packets in 
- -i' a single RTP payload, which helps to lower the congestion atihe routers as well as 

15 reduces the complexity of IP packet forwarding. 1 k : a 

The foregoing description of the exemplary embodiment of the invention has 

i: - been presented for the purposes of illustration and description! It is not intended to 

• - V^ be exhaustive or to limit the invention to the precise form disclosed?"Many . 
modifications and variations are possible in light of the above teaching. It is 

20 intendedthat the scope of the invention be limited not with this detailed description, 
; but father by th6 claims appended hereto/ • ' " : 
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WHAT IS CLAIMED IS: 

1 . A protocol for increasing the bandwidth usage efficiency of a IP 

telephone network comprising: 

creating a header for a plurality of data packets, each header providing 
5 identification of a user associated with a packet; 

adding each header to the data packet associated therewith to form mini-IP 

s; 

multiplexing the mini-IP payloads into aRTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection. 



10 



2. The protocol of claim 1 wherein the plurality of data packets are 
received from two or more users. 

3. The protocol of claim 2 wherein the identification of a user fiirther 
comprises a unique channel identifier for each of the two or more users. 

4. The protocol of claim 3 wherein the channel identifier is assigned to 
15 packets from a user when the user requests access to the IP telephone network. 

5. The protocol of claim 2 wherein the header comprises a length 
indicator, the length indicator indicating the size of the data packet associated with 
the header. 

6. The protocol of claim 5 wherein the length indicator comprises six 
20 bits for allowing a maximum of a thirty-two byte data packet. 

7. The protocol of claim 1 wherein the header further comprises a 
sequence number, the sequence number marking data packets transmitted from a 
user to identify data packet loss. 

8. The protocol of claim 7 wherein the sequence number further 

25 comprises two bits, the two bits identifying a maximum of three consecutive data 
packet losses. 

9. The protocol of claim 1 wherein the header of each data packet 
multiplexed into the RTP payload is transparent to intermediate IP routers. 
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1 0. The protocol of claim 1 further comprising de-assembling the RTP 
pay load back into the data packets. 

1 1 . The protocol of claim 1 further comprising: 

receiving at a local gateway an access request from a user at a remote IP 
5 v gateway; . _ .. - - % * v . ' ..^:.\nr .. 

transmitting a setup message to the remote IP gateway using:an IP 
connection; and 

i-*tv ^establishing ;a user plane connection for receiving data packets from a user 
after successful completion of a connection setup, ir:**?.*" iv. 



10 12. The protocol of claim 11 .further comprising: : 

, after receiving an access request from a user^determining whether an 
existing RTP/UDP/IP connection is available;" r t- '^cip 
■^rr\^cv^c,c >: .using .an.existing RTP/UDP/IFconne^^ RTP/UDP/IP 
. ''connection- is determined to be available; ' . 
f 15 £r^bk; creating a.new RTP/UDP/IP connection When an existing RTP/UDP/IP 
t l; ?v 
creating a set^message using aloca^^ 

: ■■ •;' 'v-'^-.r . - r ^Shfeeiff , 
•■ iSs^^ ' 
'.Xi.20: ;; * ^?oyering,;at the r^(^g^y^ 9 :a local:UDB:port number, remoteiport 

. imn^er v charmelidenM 

verifying at the remote gateway whether the channel identifier is free; and 
rK: ^c&^5^f^ t;; accepting the connection when T ^ identifier is free. 

14. The protocol of claim 13 wherein the accepting the connection further 

^Skr^coinprisesYr^^ i*&: 4 > :; !?*$E32? ^jfek' rf i tC? ■■■••*.££ • 

.Si" ^updating a- channelddentifier table at the remote gateway; ^ ft?" t:: 
replying to the local gateway with a connect mess^e/F- ^ '^ 

:.^h-;^:v-15.<'t The protocol of claim 14 further comprising replying to the local 
gateway vfrth ^rejection message when.a problem allocating the connection occurs. 
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16. The protocol of claim 14 further comprising: 
receiving at the local entity the connect message; 
confirming at the local entity the channel identifier; and 
informing the user requesting access. 

5 17. The protocol of claim 1 further comprising controlling the 

multiplexing and transmitting of the RTP payload using a timer. 

18. The protocol of claim 1 wherein the data packets comprise 
compressed voice data. 

19. An IP telephone network, comprising: 

I o a remote IP gateway; and 

a local IP gateway; 

wherein the remote and local IP gateways communicate using a protocol, the 

protocol comprising: 

creating a header for a plurality of data packets received from a 
15 plurality of users at the local IP gateway, eachheader providing identification of a 
user associated with a packet; 

adding each header to the data packet associated therewith to form 

mini-IP payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
20 transmitting the RTP payload over a single RTP/UDP/IP connection 

to the remote IP gateway. 

20 The IP telephone network of claim 19 wherein the identification of a 
user further comprisesaunique channel identifier for eachof the two or more users. 

2 1 The IP telephone network of claim 20 wherein the channel identifier 

25 tM*^^*™^*™^^**"™*" 
gateway. 

22 The IP telephone network of claim 19 further comprising: 
receiving at the local IP gateway an access request from a user at the remote 

IP gateway; . 
30 transmitting a setup message to the remote IP gateway using an IP 
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connection; and 

establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

. 23. . : The IP telephone network of claim 22 further comprising: 
5 after receiving an access request froma user, determining whether an 

: . c ..- existing RTP/UDP/IP connection between the local and remote IP gateways is 
■ . ^ v /; /T available;,, . . ;r^ . -> : ::,:r\:.^"T^iv ■ V: *;:»^ a,L: 

using amexisting,RTP/UDP/IP connection when;an existing RTP/UDP/IP 
>Jv _ connection. is determined to be available; _ , . ^r. i^r , 

10 creating a new RTP/UDP/IP connection when*an.existing.RTP/UDP/IP 

r:yi y j: connection's determined not to be available; and: L 

creating a setup message using a local UDP. port number,;remote port 
"Ver :iuunber 5 ^h^el;identifi^ ^l-^lr^zX & ■■.</-. 

24. The IP telephone network of claim 23 further comprising: 
i 1.5* ; ;r ^ recovering, at title .remotejIP gateway ;.albcal UDP port number, remote port 
number, channel identifier from the setuprmessage; *^ 

verifying at the remote IP gateway whether the channel identifier is free; and 
accepting the connection when the chamel identifier is free. 

^ -.20 iponnection'fu^er Emprises: * ->zz: -Ur l! : S:^i'^ yk— - ^ 
VftSK-p gstis; vja;:.; - Updating a channel identifier .table at the remote IP gateway; 1 
\, , ;• &?iv* ^rjr^ying to the local IP gateway witha connect message; 

jv-;;t'.^; r r J>m ;^ to 
the local IP gateway with a rejection message when a problem allocating the 



25: C' pomiecti6n«.occurs^* ill \ \ ct:^\ - • j: ^ *^ 



•v ;.27.-rn;..The;IP telephone network of claifn,25 fiirther.comprising: 
receiving at the local IP gateway the connect message; 
' confirming at the local IP gateway the channel identifier; and 
informingthe user requesting access. - v ^'^ 



21 



PCT/US99/17389 

WO 00/11849 

28. The IP telephone network of claim 1 9 wherein the data packets 
comprise compressed voice data. 

29 A MINI-IP controller, comprising: 

mea ns for providing control plane signaling, oon.ro! plane signaling being 

5 used ,o setup a connection to a remote peer MENI-IP controller; and 

me al f orprovidingnserp.ane S ignal,nser P lane S igna.ingbe,ngosed,o 

^atapaeLroanaeraaaoc^dwin.tnere.o.peerMim-n.connoUer 

using a MINI-IP protocol, the MINI-IP protocol compnsing: 

creating a header for a plorality of data packets, each header 
in Movidingidentificationofauserassociatedwithapacket; 

addi „ ge aehhender,on,edan,packe«associa,ed.herew,«h«ofonn 

minHP payloads; 

multiplexing the mini-IP payloads into a RTP payload; and 
transmittingmeRTPpayloadoverasingleRTP/UDP/IPconnecnon. 

15 30. TheMmi-IPcontrollerofclaim29whereinthedatapackets 

comprise compressed voice data. 

31. An RTP payload, comprising: 
an RTP header, 

a plurality of datapacke* representing data from a plurality of users; and 
a plurality of MM-IP headers, each of the plurality of packets havmg a 
^m-IPheaderan^hednaereno.eachoftheMINl-IPheaderseom^stogau^r 

Stetforidenti^goneofn.ep^ofu^heingassoeiatedvn^of 
Joad,titeMINI-IPpayloadshei„gmultiplexed K gether to fonnaRIPpacke,. 
25 32. TheRTPpayloadofolaim31ftn1hercomprisingaUDPheader. 

33. The RTP payload of claim 32 further comprising an IP header. 
34 TheRTPpayloadofolaim31 herein me identifier of a user further 
comprises a unique channel identifier for enchofthe two or more users. 
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35. The RTP payload of claim 34 wherein the channel identifier is 
assigned to packets from a user when the user requests access to an IP telephone 
network. 

. , 36. The RTP payload of claim ,3.5 wherein the MINI-IP header comprises 
5 a length indicator, the length indicator indicating the size of the data packet 
associated with the header. 

;x*i :;• ??. i The RTP payload of claim 36 wherein the length indicator comprises 
six bits for allowing a maximum of a thirty-two byte data packet. 

). ~o : 38. The, RTP payload of claim 31 wherein the MINI-IP header further 
10 . - comprises a sequence, number, the sequence number marking idata packets 1 
- transmitted from :a user to identify data packet loss. . vr v ; 

39. The RTP pay load of claim 3 8 wherein the sequence number further 
comprises twq bits^thetwo bitsidentifying a maxiinum of three consecutive data 
J- , packet losses/ v 'iV ^- ^..^ v -.: rr - .;'■■;-■?-. \ 

*15.c > . 40;; .The RTP payload ofclaim 31 wherein the MINI-IP header of each 
data packet multiplexed into Ac RTP payload is transparent to inteimediate IP 



V vrouters v :,; fc ^. .-;. lf ^ r - '*\v - v ^ -. } L >-.v. --r. 

, ^41. t The RTP payload of claim J 1 wherein the data packets comprise 

compressed voice data. \^ y. ■ ,\ .... 



20 42. , An IP network, comprising:. _ T; t . . > 

^ abase station having a MINI-IP controller; and,. , , 
aRNChavingaN^ vp 
./..i -r ^herein the base station and the RNC communicate using a protocol 'the 
pi-otocol.comprising: . ; . ; ^. , 

25 creating a header for a plurality of data packets received from a 

.... v . .. plurality, of users atthe RNC, each header providing identification of a user 
associated with a packet; : ; / 

. - adding each header to the data packet associated therewith to form 
mini-IP payloads; . , H: .^ . , n - 
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multiplexing the mini-IP payloads into a RTP payload; and 
transmitting the RTP payload over a single RTP/UDP/IP connection 

to the base station. 

43 The IP network of claim 42 wherein the identification of a user 
5 further comprises a unique channel identifier for each of the two or more users. 

44. The IP network of claim 43 wherein the channel identifier is assigned 
to packets from a user when the user requests access to the base station. 

45. The IP network of claim 42 further comprising: 

receiving at the RNC an access request from a user at the base station; 
transmitting a setup message to the base station using an IP connection; and 
establishing a user plane connection for receiving data packets from a user 
after successful completion of a connection setup. 

46. The IP network of claim 45 further comprising: 
after receiving an access request from a user, determining whether an 

1 5 existing RTP/UDP/IP connection between the RNC and base station is available; 

using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined to be available; 

creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP 
connection is determined not to be available; and 
20 creating a setup message using a local UDP port number, remote port 

number, channel identifier. 

47. The IP network of claim 46 further comprising: 
recovering, at the base station, a local UDP port number, remote port 
number, channel identifier from the setup message; 

verifying at the base station whether the channel identifier is free; and 
accepting the connection when the channel identifier is free. 
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48. The IP network of claim 47 wherein the accepting the connection 

further comprises: 

updating a channel identifier table at the base station; 
30 replying to the RNC with a connect message. 
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49. The IP network of claim 48 further comprising replying to the RNC 
with a rejection message when a problem allocating the connection occurs. 



50. . The IP network of claim 48 further comprising: 
receiving at the RNC the connect message; , . - - . - 

5 confirming at the RNC the channel identifier; and 

- v ; . < / - informing the user requesting access. . . . 

_ . ,51. The IP network of claim 42 wherein the data packets comprise 

t - r . .compressed voice data. .. >:•■:!**'■;: : ; v • .-.•/ .. ;: ' 

. , 52.. A base station having a MINI-IP controller for increasing the 
10 efficiency of .bandwidth usage in a cellular network, the MINI^IP controller 

comprising means for providing control plane signaling, control plane signaling 
^ being used to setup a connection to ,a base station controller having a peer MINI-IP 
^ ^ controller and means for providing user plane.signal v .user plane .signaling being used 
to transmit data packets to a the base station controller using ajPllrlP prptocol, 
1 5 the MINI-IP protocol creating a header for a plurality of data packets, each header 
providing identification of a mobile user associated with a , packet, adding each 
header to the data packet associated Aerevwth to fo 
, multiplexingthe mini-IP payloads into a RTT payload and transmitting the RTP 
pay load over a single RTP/UDP/IP connection. 

20 53. The base station of claim 52 wherein the '-data packets comprise 

compressed voice data. 

54. A base station controller having a MINI-IP controller for increasing 
the efficiency of,bandwidth usage in a cellular network, the MINI-IP controller 
comprising means for providing control plane signaling, control plane signaling 
25 being used to setup a connection to a base station having a peer MINI-IP controller 
and means for providing user plane signal, user plane signaling being used to 
transmit data packets to a the base station using a MINI-IP protocol, the MINI-IP 
protocol creating a header for a plurality of data packets, each header providing 
identification of a mobile user associated with a packet, adding each header to the 
30 data packet associated therewith to form mini-IP payloads, multiplexing the mini-IP 
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payloads into a RTP payload and transmitting the RTP payload over a single 
RTP/UDP/IP connection. 

55. The base station controller of claim 52 wherein the data packets 
comprise compressed voice data. 

5 56. A mobile switching center having a MINI-IP controller for increasing 

the efficiency of bandwidth usage in a cellular network, the MINI-IP controller 
comprising means for providing control plane signaling, control plane signaling 
being used to setup a connection to a base station controller having a peer MINI-IP 
controller and means for providing user plane signal, user plane signaling being used 

10 to transmit data packets to a the base station controller using a MINI-IP protocol, 
the MINI-IP protocol creating a header for a plurality of data packets, each header 
providing identification of a mobile user associated with a packet, adding each 
header to the data packet associated therewith to form mini-IP payloads, 
multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP 

1 5 payload over a single RTP/UDP/IP connection. 

57. The mobile switching center of claim 52 wherein the data packets 
comprise compressed voice data. 



<WO. 001 1848A1J_> 



26 



WO 00/11849 



1/12 



PCT7US99/17389 




PCT/US99/17389 

WO 00/11849 

2/12 



210, 



212. 



214. 



\ , 

CID 


LI 


SN 


(8 bits) 


(6 bits) 


(2 bits) 



202 



210 



1 



212 216 218 
i ^ 



CID 
(8 bits) 



LI 

(6 bits) 



T 
(1 bit) 



X 

(x bits) 



/ Mg. 2b 

204 



BNSDOCtD <WO. 



_0011B49A1_L> 



WO 00/11849 



3/12 



PCT/US99/17389 




WO 00/11849 



4/12 



PCT/US99/17389 




BNSDOCID- <WO 0011849A1J_> 



WO 00/11849 



5/12 



PCT/US99/17389 




WO 00/11849 



PCT/US99/17389 



6/12 



o 
o 

CD 



CD 

CM' 

CD 



CM 
CD 



CM 
CM 
CD 



O 
CM- 
CD 



to 



0 

CO 

o ~~ 
E 

CD 



Q 

= i 

CD C 

o -c 

E © 

CD 



Q 
CL 



E 

c 

•e 
o 
a 



CO 

3 

"55 
a 
o 



Q 
O 



co 

CO 
CO 



CD 

& ° 

.2> =5 

CO — 



3 



CM 



o 

T- 

CD 



CO 
CM 



CM 

T— 

CD 



BNSDOCID <WO_ 001184SA1_L> 



t 



WO 00/11849 



PCT/US99/17389 



7/12 



710 

Mini packets 
(speech packets) 



700 



730... 

— — 712 . / '. 

." - - ~ * \ TimervMUX (used in 

, scheduler . the packet assembly 

• ~ * _ / ^process) 

7 . \ : 



Packet assembly buffer 

A 

720 



Ms. 7 



?} **** 



V 



•a* 



RNSDOniD: <WO 0011849A1 I > 



WO 00/11849 



8/12 



PCT/US99/17389 




BNSDOCID <WO _0011849A1J_> 



WO 00/11849 



9/12 



PCT/US99/17389 




nNsnrmin- <wn nnnfuaAl I > 



WO 00/11849 



10/12 



PCT/US99/17389 




WO 00/1 1849 PCI7US99/1 7389 

11/12 




PCT/US99/17389 



WO 00/11849 



12/12 



o 
o 

CM 



O 

CO 
(M 



V 



o 

CM 



o 

LO 
CM 



O 

CO 
CM 



O 
CM 



O 



o 



O 
LO 



o 

CO 

*" CO 
LX 
LL) 

o (f) 



--<= \ 



CO T 
CM CO 

cm 

S3 



CD ^ 

CvJ CD 

N- CM 

CD ^ 

I 9= 



o 

T- 

CM 




o 



o 
to 



o 

CO 



o 

O) 



o 

GO 



o 



o 

CD 



o 

LO 



o 



o 

CO 



o o 

CM t- 



peaqjaAO % 



\ 



o 

CM 
CM 



BNSDOC1D <WO 0011849A1_L> 



INTERNATIONAL SEARCH REPORT 



Interr nal Application No 

PCT/US 99/17389 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7- H04L29/06. -H04L12/64 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 H04L 



Documentation searched other than minimum documentation to the extent that such documents are Included In the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category •■ 



Citation of ^document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



J.ROSENBERG, H/SGHULZRINNE: "An RTP V? 

fayload Format for User Multiplexing" \;v 

INTERNET DRAFT , 'Online! .:M-;>vT 

6 May 1998 (1998-05-06), pages 1-10, 

XP002127739 . 
''Retrieved .from the Internet: 
. '<URli ': http : //ee.. mokwon . ac ,kr/%7E j spark/rtp/ 
1 standard/ tnternet-drafts/draft-1etf-avt-ag 

gregation-00;txt>. 

- retrieved on 2000-01-14! 

the whole! document 

■ ".-i . ; ." "~ -/-- 



1,19,29, 
31,42, > 
52^54,56 , 



Further documents sare listed in the continuation of box C. 



□ 



Patent family members are listed in annex. 



0 Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the international 

filing date 

V document which may throw doubts on priority clalm(s) or 
which Is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T later document published after the International filing date 
. or priority date and not In conflict with the application but • 
cited to understand the. principle or theory underlying the 
invention 

"X h document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to Involve an Inventive step when the 
document Is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

-& 0 document member of the same patent family 



Date of the actual completion of the international search 



14 January 2000 



Date of mailing of the International search report • 



i 



02/02/2000 



Name and mailing address of the ISA 

European Patent Office, P.B. 581 8 Patentlaan 2 
NL-2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



RAMIREZ DE AREL.., F 



Form PCT/1SA/210 (second sheet) (July 1992) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



Intern wl Appllcotlon No 

PCT/US 99/17389 



-rnn.lnunt.on) DOCUM ENTS CONSIDERS l UHERBI^M T____ 

> - 1 C— n 5 * g .no.caUon.wne, app.op na.e. 5 mo SS » 



Relevant to claim No. 



ic TAN1GAWA T HOSHI, K.TSUKADA: "An RTP 
S1™1 MuUlpiexW Transfer Method for 
Internet Telephony Gateway 
INTERNET DRAFT , 'Online! 740 
16 June 1998 (1998-06-16), XP0021Z//4U 
Retrieved from the Internet: 
URL ftp : /MP. bbnplanet corn Internet- -draf 
ts/draf t-tan1 gawa-rtp-mul t l pi ex-00 . txt> 
'retrieved on 2000-01-14! 
the whole document 

B SUBBIAH, S. SENG0DAN: "User 
Multiplexing in RTP payload between IP 
Telephony Gateways" 

1 one/pro jects/1 pt/pl ayers/i etf /draft l eu 
avt-mux-rtp-00.txt> 
'retrieved on 2000-01-14! 
the whole document 



1,19,29, 

31,42, 

52,54,56 



1-57 



Form PCT/ISA/210 (con»nu..l.n o. Mcond she.» (July 1992) 
BNSDOCID <WO_ 001164BA1J_> 



page 2 of 2 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects iri the images include but are not limited to the items checked: 



□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLACK BORDERS 



THIS PAGE BLANK 



